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(57) Abstract 

A system and method for effectuating Electronic Funds Transfer credit messages. The main structural components of the system 
include a Payment Portal Processor (PPP), an Internet Pay Anyone (IPA) Account, a Virtual Private Lockbox (VPL) and an associated 
Account Reporter, the existing EFT networks, and a cash card for accessing a VPL or IP account. The PPP is a software application 
that provides a secure portal for accessing (linking to) either the user's Demand Deposit Account (DDA) or an IPA account and can be 
combined with the functionality of a traditional digital Wallet. Consumers use a PPP enhanced Wallet to fund their account, shop on the 
web, pay bills, pay anyone, store electronic receipts and transaction history, and check their recent PPP enhanced Wallet activity. The 
IPA account is a special purpose account with limited functionality for making electronic payments in the form of EFT credit messages. 
The VPL is a limited function receive only account for receiving electronic payments through the EFT. The Account Reporter is a portal 
to view transaction history and balance of IPA and VPL accounts, provide online, real-time transaction reports, and to reconcile accounts 
receivable^purchase records against incoming EFT payment records. A physical card can be associated with either an IPA or VPL account 
in order to provide PIN debit capability. 
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A VIRTUAL PRIVATE LOCK BOX 

FIELD OF THE INVENTION 

The present invention generally relates to systems and 
methods for conducting electronic commerce, and more particularly to 
systems and method in which a payor pushes electronic credits to a payee 
using an Electronic Funds Transfer system. 

BACKGROUND OF THE INVENTION 

Presently, there are several methods by which a consumer 
can electronically pay for purchases made on the Internet, such as credit 
cards, off-line debit cards, online debit cards, digital cash, and smart cards. 
Each of these methods has its own advantages and disadvantages. An off- 
line debit card uses the traditional credit card system for clearing the 
payment but no Personal Identification Number (PIN) is required. The use 
of an on-line debit card requires that the consumer supply his or her PIN, 
and the amount of the purchase is debited from the consumer's account 
instantaneously. One disadvantage with both the on and off-line debit 
cards, from a consumer's point of view, is the inability to reverse or 
repudiate the transaction. In contrast, by use of a credit card, the consumer 
at a later date can reverse the transaction (e.g., if the purchased goods are 
never shipped to the consumer). 

It is predicted that credit cards will be the dominant on-line 
point of sale (POS) payment choice for at least the next five years. While 
new Internet payment mechanisms have been rapidly emerging, consumers 
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and merchants have been happily conducting a growing volume of 
commerce using basic credit card functionality. None of the emerging 
efforts to date have gotten more than a toehold in the market place and 
momentum continues to build in favor of credit cards. 

At the present time, there are several large market segments 
for an online payment system. First, high volume, low dollar payments 
from consumers to providers of on-line digital intellectual products or 
services such as written materials, music, software or games. These can 
either be 'Intrapreneurs,' individuals or small merchants marketing their 
products directly to consumers, or larger intermediaries, either traditional 
retail merchants or auction sites that aggregate consumers and sellers to 
facilitate sales. A second large market segment involves electronic 
payments from consumers to other consumers. A third and growing market 
segment resides in business to business electronic payments. 

The market opportunity will continue to explode as what is 
currently thought of as the Internet continues to expand. In general, the 
Internet is thought of as Personal Computer (PC) and telephone based. 
However, that model is quickly changing to include broadband 
communication via terrestrial links such as Digital Subscriber Line (DSL), 
wireless and two-way cable. The end number of devices is also expanding 
to include cellular phones with video displays as well as interactive 
television, Personal Digital Assistants (PDAs) and kiosks with Internet 
access. Both of these changes will only serve to increase the number of 
end points and consumers who will have a need for high- volume, low 
dollar payment capabilities. 

Overall, retail consumer sales as well as business to business 
sales on the Internet are projected to grow exponentially. The bulk of the 
payments for these sales are expected to be done with credit cards, which 
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are widely available and owned, are supported by an established 
infrastructure and provide merchants and consumers with a high degree of 
surety of payment and receipt. While there are clear differences in the 
ways in which consumers use credit cards, traditionally, consumers have 
5 used them for larger dollar purchases. In recent years, debit cards have 

entered the market and have been used as cash and check replacements, 
replacing lower-dollar volume transactions for purchases of consumable 
products such as food and gasoline. 

Debit and credit card transactions are currently processed 

10 using the Electronic Funds Transfer EFT network. The debit message 

comprising the transaction is carried over the EFT network from the point 
of origination (e.g., a Point of Sale (POS) location, an ATM machine, or an 
Internet merchant) to the financial institution that issued the card (or its 
representative). Currently, only debit messages are carried by the EFT 

15 network, including debit reversal messages. A debit reversal message 

reverses a previously processed debit transaction and is generally not 
considered a credit. 

U.S. Patent 5,220,501 to Lawlor, et al., describes a home 
banking and bill payment system that uses the EFT network. As described 

20 in the patent, the systems and methods of Lawlor performs a traditional 

debit pull from the user's bank account using the EFT network and 
subsequently makes payments using conventional means such as the ACH 
network or paper checks. Furthermore, the system of Lawlor uses a 
centralized computer to which the user attaches via a dedicated phone 

25 connection as opposed to connecting through the Internet. 

Although credit and debit cards have emerged as the most 
popular form of payment over the Internet, there are drawbacks associated 
with each of these payment types. Notably, each have a relatively high 
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cost that includes a processing fee plus a merchant discount of 1 .4% and 
up. The relatively high fees support the credit card business model. While 
credit and debit cards may continue to be a viable payment option for 
merchants selling relatively high ticket items over the Internet, credit and 
debit cards are not economically viable for purchases of lower cost items. 
For lower-cost items, the relatively high transaction processing fees plus 
the discount result in the transaction processing fee consuming a relatively 
high proportion of the total revenue generated by the product sale. These 
characteristics of a low cost item lend themselves to a low cost payments 
solution that is guaranteed, yet does not require the payee to bear the 
burden and risk of authentication. 

The Internet is spawning a direct model in which 
manufacturers of products or services are able to deal directly with 
consumers. This model has several implications for the payment process. 
First, by eliminating the middleman, the direct model is resulting in intense 
price' competition, with manufacturers having much tighter margins. This 
competition creates the need to minimize all costs especially payment 
processing costs. Second, the Internet enables the development of large 
numbers of independent producers to 'set up shop' on the Internet and 
immediately have access to large numbers of consumers. Third, a large 
and increasing number of intellectual products such as publications, music, 
video, software, games are more efficiently distributed digitally over the 
Internet rather than through traditional physical (paper or disc) media. 
While this trend has already started, as higher bandwidth and increasingly 
sophisticated devices enter the marketplace, it is expected to increase 
significantly. Many of these purchases will have the following 
characteristics: low cost to the consumer and the ability to purchase 
individual works (i.e.: a song, a video, an article, a game). These 
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characteristics call for a payment form that has a low cost. 

By combining these two trends - direct merchant to consumer 
distribution from independent 'intrapreneurs 5 , and the ability to distribute 
products digitally - a new marketplace has emerged for low dollar, high 
5 volume, real-time payments with payment surety for both consumers and 

producers. Larger intermediaries, such as existing on-line merchants and 
auction sites will also benefit from a low-cost payment device for high- 
volume, low-dollar payments for all of the same reasons outlined above. 
On-line merchants are currently facing a variety of problems including a 

1 0 low volume of on-line purchases relative to the number of site viewers; a 

high volume of charge-backs for on-line purchases; non-integrated 
'patchwork' systems for payment processing; high fraud rates and high 
processing fees. All of these factors serve to depress the potential number 
of customers who are comfortable purchasing on line as well as depressing 

1 5 the profitability of on-line merchants. 

Furthermore, to date, there is no efficient way for consumers 
to make payments to other consumers using the Internet. All traditional 
forms of person-to-person exchange include the physical exchange of cash 
or checks rather than a real-time digital exchange of value. In addition, the 

20 high cost of retail wire transfers (i.e., Western Union) is cost prohibitive to 

a significant portion of society. 

Automated Clearing House (ACH) payments have begun to 
be used with respect to payments made via the Internet. These types of 
transactions typically involve payments made with respect to loans, 

25 insurance and utilities. It is predicted that ACH payments will not be 

widely deployed to on-line POS for two reasons. First, an ACH transaction 
does not provide transaction authorization, and secondly, authentication 
requires a pre-existing relationship between the customer and the merchant. 
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Furthermore, ACH payments have to be received, deposited and cleared 
before the funds are available. In contrast to ACH transactions, credit and 
off-line debit cards require authorization but not authentication. Similarly, 
on-line debit requires authentication (i.e., a PIN or other authentication). 
As with credit and debit card transactions, ACH transactions requires that 
the user provide the merchant (payee) with the "keys" to the user's 
account. This pull model of effectuating payments again raises the security 
concerns discussed herein (e.g., fraud). 

Two significant drawbacks with some or all of the above 
models for Internet POS payments are that: 1) a pre-existing relationship 
between the consumer and the merchant must exist; and 2) the consumer is 
required to provide the merchant with his or her account and/or PIN. The 
first drawback of some of the above models cannot be practically overcome 
as it is impossible for a consumer to have pre-existing relationships with all 
1 5 of the potential merchants conducting business on the Internet. With 

respect to the provision of the consumer's account and PIN number over the 
Internet, even though mail order companies have been operating in this 
manner for years, many consumers feel uneasy about electronically 
providing their account and PIN numbers to strangers over the Internet. 

Figure 1 depicts the conventional debit/credit transaction 
model. In this model, if the consumer 100 desires to buy a compact disc 
(CD) from a web retailer 110, the consumer 100 electronically transmits its 
debit or credit card number and/or PIN to the web retailer 110. Upon 
receipt of this information from the consumer 100, the retailer 1 10 submits 
25 the proposed transaction to its bank 120 or merchant acquirer via the EFT 

system (not shown) for approval. The merchant's bank 120 then contacts 
the bank 130 (issuer bank) which issued the debit/credit card to the 
consumer 100. The issuer 130 checks the consumer's balance on the card 
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and either approves or rejects the proposed transaction. This approval or 
denial is transmitted from the issuer bank 130 back to the merchant bank 
120 which then informs the web retailer 1 10 of the approval or denial. If 
the charge to the debit/credit card was approved, the transaction is 
5 completed by the web retailer 110 shipping the goods to the consumer 100. 

Some of the same drawback described above with respect to 
Internet shopping equally apply to electronic bill payment. The first 
drawback, requiring a pre-existing relationship between the consumer and 
bill payee is not as great a concern because this relationship most likely 

10 already exists between the consumer and the payee (e.g., the telephone, 

cable or utility company). The second drawback which requires the 
consumer to provide the payee with his or her account and/or PIN still 
remains a concern with electronic bill payment. Although fraud is less of a 
problem for bill payment, since the consumer presumably has regular 

1 5 dealings with the payee, some consumers still view the provision of the 

payee with at least his/her account number a diminution in the consumer's 
privacy. 

SUMMARY OF THE INVENTION 

The present invention represents a new paradigm for 

20 effectuating electronic payments that leverages existing platforms, 

conventional payment infrastructures and currently available web-based 
technology to enable e-commerce in both the virtual and physical 
marketplace. The concept provides a safe, sound, and secure method that 
allows users (consumers) to shop on the Internet, pay bills, and pay anyone 

25 virtually anywhere, all without the consumer having to share account 

number information with the payee. Merchants receive immediate 
payment confirmation through the Electronic Funds Transfer (EFT) 
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network so they can ship their product with confidence that the payment 
has already been received. The present invention further enables small 
dollar financial transactions, allows for the creation of "web cash" as well 
as provides facilities for customer service and record-keeping. 

5 The structural components to the system of the present 

invention include: a Payment Portal Processor ; a digital Wallet; an 
Internet Pay Anyone (IP A) Account; a Virtual Private Lockbox (VPL); an 
Account Reporter; the existing EFT networks; and a cash card. The 
Payment Portal Processor (PPP) is a software application that augments 

1 0 any Internet browser with e-commerce capability. The PPP software sits in 

front of and provides a secure portal for accessing (linking to) the user's 
Demand Deposit Accounts (DDA) and IP A accounts. The PPP enables the 
user to push electronic credits from its DDA and IPA accounts to any other 
accounts through the EFT network. 

1 5 Although the PPP can be used as a stand alone product, in a 

preferred embodiment, the functionality of the PPP is directly incorporated 
into a new form of PPP enhanced digital Wallet in order to enhance the 
consumer's Internet shopping experience. Alternatively, hooks to the PPP 
can be incorporated into existing digital Wallets to add the unique payment 

20 feature of the PPP. Furthermore, features of online banking (e.g., funds 

transfers) can be incorporated into the PPP to allow for account 
maintenance and IPA account funding. In association with the traditional 
Wallet functionality and the Account Reporter of the present invention, the 
PPP is used to fund consumer's accounts, shop on the web, pay bills, pay 

25 anyone, store electronic receipts and transaction history, and review the 

user's recent account and shopping activity. The PPP thus provides 
consumers with a safe, secure, and convenient way to conduct financial 
transactions over the Internet. 
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The majority of the prior art electronic Wallets on the 
Internet today are primarily used as a convenience vehicle, merely 
providing a method of storing account number information and other form 
filling functions (e.g., shipping addresses). In contrast to traditional 
5 Wallets, the PPP enhanced Wallet of the present invention is associated 

with one or more DDA and/or IPA accounts. The PPP thus provides the 
user with a form of virtual cash that is secure and guaranteed. The PPP 
further contains a receipt feature and archive feature that maintains a 
transaction history of all payment activity with respect to accounts linked 

10 to the PPP. The PPP further has the capability to store miles, coupons, 

sweepstakes or other marketing incentives associated with use of the 
accounts linked to the PPP. The PPP enhanced Wallet enriches the 
consumer e-commerce experience by eliminating the tedious process of 
filling out lengthy payment and shipping fields as this is done 

15 automatically. Merchants significantly benefit from the credit push and 

form filling features of the PPP enhanced Wallet, since research indicates 
that most e-commerce purchases are abandoned at the POS due to 
consumers' unwillingness to complete lengthy forms or provide personal 
credit card numbers. Furthermore, the automatic form filling features of 

20 the PPP enhanced Wallet reduces shipping errors, as the "ship to" address 

is automatically filled in, eliminating manual entry errors. 

The IPA account is a special purpose account with limited 
functionality for originating electronic payments. Funds in an IPA account 
can only be accessed electronically by the user of the account using 

25 standard authentication procedures (e.g., a PIN). The electronic access to 

the IPA account can be accomplished through a PC, card reader, PDA, 
Interactive TV and cell phone technology, for example. This restriction 
provides an added level of consumer protection in that the consumer never 
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has to provide any of its account information to any strangers. The above 
described PPP (operated by the user) securely communicates with the IPA 
account to initiate payments according to the present invention. One 
essential feature of the present invention, completely contrary to the prior 

5 art, is that payments made from the IPA account are transmitted to the 

payee as a credit over the secure EFT network. As discussed above, only 
debit related transactions are currently initiated on the EFT system. The 
EFT credit message of the present invention thus represent a significant 
advancement in art which has no peers with respect to electronic 

10 commerce. 

Similar to an IPA, the VPL is a limited function account. 
While an IPA can be accessed electronically, a VPL is constructed with a 
"receive only" functionality that enables a merchant (or any party) to 
receive electronic payments through the EFT. Therefore a VPL is a secure 

1 5 address that can be provided to the public as a means of receiving funds. 

These funds can then be automatically swept to either the user's 
corresponding DDA or IPA account, preferably once a day. As will be 
further described below, there are several types of VPL accounts according 
to the present invention: one for consumers, one for merchants and one that 

20 is initially linked to a cash card as described below. The card VPL is a 

receive only account that can only be debited via the use of the cash card 
and a PIN. The consumer and merchant VPLs can similarly be PIN debited 
to access the funds in the account. Unlike an IPA account, the VPL 
account cannot be used for initiating EFT credit messages. In one 

25 embodiment of the present invention, the IPA and VPL accounts are 

logically one account with two addresses for account. One address, (the 
IPA address) is only known to the user (and its issuing institution) and is 
used to make payments from the account. The other address, the VPL 
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address, is used to receive electronic credits and can be freely published 
without any fear of fraud. 

The Account Reporter is a portal for consumers or business 
to view the balance and transaction history of an IPA or VPL account. In 
5 addition to the features described above intended for use with an IPA 

account, the Account Reporter includes special functionality intended for 
use by merchants in association with their VPL accounts. The Account 
Reporter provides online, real-time transaction reports, and reconciles 
accounts receivable/purchase records against incoming EFT payment 

10 records. In addition, the transaction history of the VPL can be archived 

and retrieved via a payment search engine in the Account Reporter. This 
provides the merchant with powerful data mining, customer service, and 
order fulfillment (warehouse, shipping, supply chain management) tools at 
their fingertips. Credit card purchases on the web according to prior art 

15 methods are not connected to a cash management program. In contrast to 

these prior art systems, the VPL, connected with the Account Reporter, 
offers a complete purchasing and cash management opportunity for a 
merchant. The VPL and Account Reporter combination provides a 
merchant with instant payment receipt verification, accounts receivable 

20 functionality, order fulfillment facilitation, inventory control/supply chain 

management facilitation and data mining capability. 

The Account Reporter is a flexible component offering 
instant payment confirmation, reconciliation and record retention so that 
merchants can track purchase orders against actual payments in real time. 

25 Every VPL transaction can be stored, searched, and retrieved. This 

archival/retrieval functionality is the perfect instrument for customer 
service and data mining. The Account Reporter offers all of the above 
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features, without the need to actively engage in funds management as is 
required with the prior art. 

Using the structures described above, the methods of the 
present invention allow consumers and businesses to conduct secure and 
economical shopping on the Internet, to pay anyone online, pay anyone 
funds online, pay bills electronically online, and even use a linked cash 
card. The methods and structures of the present invention enable e- 
commerce in both the virtual and physical marketplace through the use of 
legacy platforms, the conventional payments infrastructure and currently 
available web-based technology. 

The present invention furthermore solves many, if not all, of 
the problems of the prior art described above. Currently, all Internet 
transactions use "pull" technology in which a merchant must receive the 
consumer's account number (and in some cases PIN number) in order to 
complete a payment. The payment methods of the present invention 
conversely use "push" technology in which users (consumers or 
businesses) push an EFT credit from their IPA or DDA accounts to a 
merchant's account, without having to provide their own sensitive account 
information. 

The present invention provides an enhanced level of security 
because sensitive financial information is not carried over the Internet. All 
of the financial transactions are executed through the secure EFT network. 
This method of the present invention provides buyers and sellers with the 
comfort that their transactions are both secure and private. Furthermore, 
since payment confirmations are immediately received through the EFT 
network, sellers can rest assured that the buyer's funds are "good" before 
the purchase transaction is completed (i.e., before the goods are released 
(shipped) to the consumer). 
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The present invention provides significant economic 
advantages over the prior art systems and methods. The majority of the 
technology required to implement the present invention already exists, 
which results in reduced startup costs for an institution practicing the 
5 present invention. Payments made according the present methods pass 

through a mature, established EFT switch which results in a low transaction 
cost. The payment mechanisms of the prior art are not optimal for 
processing small dollar transactions. However, the efficient, low cost 
architecture of the present invention supports payments of any size and is 

10 perfect for low dollar purchases. This architecture supports the growing 

need for Internet micro-payments for goods such as on line articles and 
music files, yet supports large value payments as well. 

By the structures and methods of the present invention, the 
two most significant disadvantages of the prior art online shopping 

15 methods described above have been overcome. First of all, the buyer 

(consumer or business) is no longer providing its confidential financial 
information to strangers over the Internet. Rather, the buyer is dealing 
directly with its own trusted institution (in a preferred embodiment a bank). 
Furthermore, no pre-existing relationship has to exist between the customer 

20 and the merchant. 

For the merchant, the present invention significantly reduces 
the transactional cost as compared to the use of credit cards. The method 
also provides a reduction in fraud and credit losses, while the finality of the 
transaction virtually eliminates dispute and chargeback processing from the 

25 viewpoint of the financial institution. For financial institutions, the present 

invention all but eliminates the potential of fraud that is inherent with credit 
card transactions. As consumers are typically only responsible for the first 
S50 of fraudulent transactions, banks typically absorb the sometimes 
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significant costs associated with fraud. The ability for hackers to steal 
consumer's account numbers (e.g., credit card numbers) from an Internet 
merchant is completely eliminated since the merchant never receives such 
information. 

The present invention is not limited to the case of a consumer 
making purchases from Internet merchants or business to business 
transactions. The method has further, broader applicability by providing 
the ability for anyone with an account at an institution to transfer funds to 
anyone else who also has an account at the same or a different institution. 
The pay anyone feature of the present invention allows parties to 
electronically transmit funds instantaneously without the expense of 
today's wiring fees. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For the purposes of illustrating the present invention, there is 
shown in the drawings a form which is presently preferred, it being 
understood however, that the invention is not limited to the precise form 
shown by the drawing in which: 

Figure 1 illustrates the prior art method of Internet payment 
processing using debit and/or credit cards; 

Figure 2 depicts a first embodiment of the present invention 
that enables Internet shopping; 

Figure 3 depicts a pay anyone embodiment of the present 

invention; 

Figure 4 illustrates a prepaid cash card embodiment of the 
present invention; 

Figure 5 illustrates a pay anyone embodiment of the present 

invention; 
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Figure 6 illustrates a bill payment, biller direct embodiment 
of the present invention; 

Figure 7 illustrates a bill payment, service provider 
consolidation embodiment of the present invention; 
5 Figure 8 illustrates a bill payment, customer consolidation 

embodiment of the present invention; and 

Figure 9 illustrates a structure and process for funding an 
account associated with an electronic Wallet according to the present 
invention. 

1 0 DETAILED DESCRIPTION OF THE INVENTION 

In contrast to the credit card, on-line and off-line debit and 
other payment models existing today, one of the unique features of the 
method of the present invention is the flow of the payment instruction and 
the payment which follows. In the credit card, on-line and off-line debit 

15 models, a buyer provides a seller with an instruction that authorizes the 

seller to collect funds from the buyer's account. Depending on the system, 
this debit instruction results in a guaranteed payment in the case of an on- 
line debit rather than a lengthy wait for funds (such in the case of a check) 
or something in between in the case of an off-line debit and credit card. 

20 The difference between the prior art models and the model of the present 

invention can be described as the difference between a "pull" and a "push" 
model. In the conventional models of today, the seller "pulls" the payment 
from the buyer's account using a debit instruction, while in the present 
invention the buyer "pushes" an EFT credit to the seller's account. 

25 Figure 2 illustrates a first embodiment of the present 

invention in which a consumer (including businesses acting as consumers) 
can perform Internet shopping. Figure 2 further illustrates the main 
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structural components of the present invention. Element 200 represents the 
device through which the consumer accesses the Internet. In a preferred 
embodiment, the workstation 200 is a Personal Computer (PC) loaded with 
an Internet browser 210 such as Netscape™ Navigator™ or Microsoft™ 
5 Internet Explorer™. In alternative embodiments, the user can access the 

Internet using any Internet ready device such as a web enabled ATM 
machine or a Personal Digital Assistant (PDA) such as a Palm Pilot™, a 
cell phone or an interactive TV. The present invention is not limited by 
any particular physical device and can employ any device that provides 

1 0 access to the Internet. For example a public kiosk which provides access to 

the Internet can be used to practice the present invention. 

As the user accesses the Internet using its Browser 210, a 
Wallet 21 5 is launched by the user. The Wallet 215 can be downloaded 
and installed from a website. Using thin wallet technology, the majority of 

1 5 software and databases comprising the Wallet 215 resides on a host web 

server and the user accesses the Wallet 215 through a website or a button 
(e.g., icon) on the Browser 210. Some functionality of the Wallet 215 can 
be operated on the workstation 200 itself, without the requirement of 
attachment to the Internet. In addition to PC-based access as described 

20 above, the Wallet 215 can be downloaded to various non-PC devices such 

as PDAs, cellular telephones, and interactive TV's. The consumer may 
access the Wallet 215 while logged onto the Internet by selecting a wallet 
button on the Browser 210 toolbar, or selecting a wallet icon at the 
merchant's web site. For non-PC devices, the Wallet 215 can be activated 

25 via a separate application, a browser link, or through a sponsoring website. 

In a preferred embodiment of the present invention, a business, such as a 
bank, operates the server that hosts the Wallet 215 Application 
Programming Interface (API). This embodiment provides for additional 
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security of the connection between the Wallet 215 and the user's IPA 230 
or other accounts maintained at the institution. 

Figure 2 depicts the preferred embodiment of the present 
invention in which the Wallet 215 incorporates all of the functionality of 
5 the PPP 227 into a single component. Such a PPP enhanced Wallet 215 

performs all of the conventional (e.g., form filling) functions of a 
traditional wallet and further has the payment capability of the PPP 227 as 
described below. As alternatively depicted in Figure 3 (discussed below) 
the Wallet 2 1 5 can be the conventional form filling wallet with the 

10 appropriate interface to the PPP 227. In a third embodiment (illustrated in 

Figure 5 discussed below), the Wallet 215 is not used at all, and the PPP 
227 operates as a stand alone component for generating the payment 
authorization. The following discussion of the PPP enhanced Wallet 215, 
particularly in regard payment functions apply equally to the PPP 227 

15 when used as a stand alone component or when used in conjunction with a 

traditional wallet. 

The user's log-in to the PPP enhanced Wallet 215 is secure 
and encrypted to protect the confidentiality of any financial information 
associated with the operation of the PPP enhanced Wallet 215. Once 

20 accessed, a window containing the PPP enhanced Wallet 215 is launched 

on the workstation 200 and remains open during the user's session. The 
PPP enhanced Wallet 215 window has the ability to communicate with 
other open browser windows. In a preferred embodiment, the user's 
connection to the PPP enhanced Wallet 215 is through the Internet. In an 

25 alternative embodiment, the connection from the user's workstation 200 to 

the PPP enhanced Wallet 215 software can be through a separate dial up 
line or third party private network. 
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As one of its primary functions, the PPP enhanced Wallet 
215, though the functions provided by the PPP 227 serves as the portal to 
an Internet Payment Account (IP A) or a DDA account 230 described in 
more detail below. In a preferred embodiment the PPP enhanced Wallet 
5 215 stores the following types of information: Form filling information 

such as credit card numbers, debit card numbers, shipping addresses, 
alternate shipping addresses, frequent flyer accounts, membership 
discounts (e.g., AAA, AARP), loyalty programs and e-mail addresses; 
Discount information such as e-coupons, rebates and merchant-specific 
10 spending certificates; Points or miles accrued for use of the accounts 

associated with the PPP 227; and Convenience information such as 
frequently paid VPL # 5 s (described below), bill payment account #'s, 
receipts, e-commerce bookmarks, shopping lists. A preferred download 
folder is installed on the user's local hard drive. The PPP enhanced Wallet 
15 215 has pull down menus that are used to select, edit, update, sort, import 

and export any of the above information. 

Using the above information, the PPP enhanced Wallet 215 
automatically fills in electronic merchant purchase forms with the user's 
shipping address, e-mail address, discount numbers, etc. The PPP 
20 enhanced Wallet 215 supports virtual cash (IPA/DDA) payments in 

accordance with the present invention, traditional credit and debit card 
"pull" payments and a combination of the two types of payments as is 
further described below. Upon receipt of an electronic purchase message 
from a merchant web site 255 as will be further described below with 
25 respect to the method of Figure 2, the PPP enhanced Wallet 215 user is 

able to: 1) approve a purchase; 2) initiate the payment through a payment 
authorization to the consumer's bank 220; 3) verify the accuracy of the 
merchant's payee information (identification of the merchant's account 235 
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at the merchant's bank 275); 4) generate a purchase confirmation 244 that 
is transmitted to the merchant web site 255 or VPL reporter 240; and 5) 
generate a receipt that can be stored at the server hosting the PPP enhanced 
Wallet 215 or the user's storage (e.g., hard drive) on workstation 200. The 
5 PPP enhanced Wallet 215 user receives a confirmation message indicating 

that no purchase has been made if a purchase is not completed. 

The PPP enhanced Wallet 215 includes a "Time Out" feature 
whereby purchase requests not approved by a user for a set amount of time 
(e.g. 10 minutes) will be invalidated. For "Pay Anyone" payments as 

10 further described with respect to Figure 3 below, the PPP enhanced Wallet 

215 supports a user defined recission period (e.g., 30 minutes) during 
which the user can reverse a transaction. 

An additional feature of the PPP enhanced Wallet 215 are 
parental control settings. In establishing an IPA account, the user is given 

15 the opportunity to establish subordinate (child) IPA and/or VPL accounts 

that are controlled by the main (parent) IPA account. For example a parent 
might want to establish an IPA/VPL account for each of its children. 
Through the IPA account linked to the parent's PPP enhanced Wallet 215, 
the parent is able to view and control all aspects of the children's IPA/VPL 

20 accounts. For example, the parent might limit the funding of the children's 

accounts such that they can only receive funds from the parent's account. 
This will prohibit strangers from sending money the children's accounts. 
The parent could also limit the amount or number of any transactions out 
of the account or limit (block) any payments to unapproved VPL accounts 

25 (e.g., associated with unapproved Internet sites) 

Using functionality from online banking services, the PPP 
enhanced Wallet 215 is able to be associated with (linked to) some or all of 
the accounts maintained by the user at the bank 220. The user is thus able 
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to transfer funds, amounts, value, from one account to another (e.g., to an 
IP A account 230 from a savings account, or VPL account 235) with ease. 
Although in the preferred embodiment of the present invention, the IPA 
230 and VPL accounts are maintained at a financial institution (e.g., a 
5 bank), it is readily appreciated that any businesses that can attach to the 

EFT network 270 are capable of maintaining the accounts 230, 235 and 
performing the operations of the present invention. 

A unique transaction number is included in any payment 
communications to and from the PPP enhanced Wallet 215. All of the 

10 payment communications are stored by the PPP enhanced Wallet 215 for 

review and auditing by the user. Examples of stored payment 
communications include payment messages from a merchant or billers, 
payment authorizations from the PPP enhanced Wallet 215 to the bank 220, 
and payment confirmations 244 to the merchant (255 or 240). The 

15 transaction number for a particular transaction is included in each 

communication and allows for swift correlation and indexing of 
communication records (e.g., reconciliation). The PPP enhanced Wallet 
215 interfaces with the Account Reporter described below, which will have 
access to all archived transactions. In a preferred embodiment, the 

20 payment communication records are stored in a common database and both 

the PPP enhanced Wallet 215 and the Account Reporter associated with 
(attached to) a particular accounts are able to access the common database 
for these accounts. Transactions are stored for audit as well as disaster 
recovery purposes. The PPP enhanced Wallet 215 allows the user to view 

25 all transaction histories including receipts and messages. These historical 

items are sortable by date, function (bill payment, pay anyone, shopping, 
etc.), amount, payments initiated or received, merchant, etc. 
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As is further described below, the PPP enhanced Wallet 215 
is responsible for initiating the push of the credit to the merchant's account 
235. In order to perform the credit push over the EFT, the PPP enhanced 
Wallet 215 requires the merchant's payee information that uniquely 
5 identifies the merchant's Virtual Private Lockbox (VPL) 235. This payee 

information includes the merchant's bank 275 identification number 
(typically six digits) and the number of the VPL account 235 (typically ten 
to thirteen digits). This payee information constitutes an address to which 
the Wallet 215 can push credits. Payment communications from PPP 

10 enhanced Wallet 215 can additionally identify the PPP enhanced Wallet 

215 user's name (if required) and include the unique transaction number. 
The PPP enhanced Wallet 215 can make repeated payments (daily, weekly, 
etc) as well as scheduled payments (on a specific calendar day or in a 
specific # of days). If the PPP enhanced Wallet 215 is linked to a DDA 

15 account, DDA debits such as checks, returned checks, ACH payments, etc. 

are not charged against funds in the primary IPA account 230 associated 
with the PPP enhanced Wallet 215. Users are required to acknowledge 
acceptance of a PPP enhanced Wallet 215 agreement prior to their first 
transaction using the PPP enhanced Wallet 215 including a requirement to 

20 return any proceeds received in error. 

Prior to conducting any on-line purchases or making any 
payments using the methods of the present invention, the consumer 
establishes an Internet Payment Account (IPA) 230 with its bank 220. 
Alternatively, a DDA account 230 can be used, but this is less preferable. 

25 For one reason, it is envisioned that only small payments are to be made 

from the IPA account 230 and accordingly less funds would be kept in the 
account as opposed to the funds normally maintained in a DDA account. 
The IPA account 230 is a specialized account used 
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specifically for electronic commerce in accordance with the present 
invention. Once the IP A account 230 has been established, the user is able 
to fund this account 230 from its normal DDA checking or savings 
accounts, consumer's Line of Credit, or credit, or debit card account held 
by the bank 220 or any other account from which the consumer can transfer 
funds (e.g., another DDA account or credit card account at another 
financial institution). The IPA account 230 provides the user with a 
confirmation capability in order to verify that the amount drawn is correct. 
The IPA account 230 and the VPL account 235 (described below) both 
allow PIN debit transactions for withdrawals from the accounts. 

In a preferred embodiment, the IPA account 230 is combined 
with a VPL account 235 into a single account. The IPA account 
functionality is accessed through a first address to the account by which 
funds can be transferred out of the IPA account. Only the user has access 
to this address and it is password and or PIN protected. If the user has 
several IPA accounts, when the user accesses its PPP 227, a single 
password and or PIN procedure provides access to all of the user's 
accounts. The VPL functionality makes the single account appear as a 
receive only account and is accordingly accessed through a second, 
preferably different address. This second address can only be used for 
receipt of credits, preferably electronic credits according to the present 
invention. Since the second address can only be used to receive funds, the 
user can freely publish the address without any fear of someone 
fraudulently transferring money out of the account. The VPL portion of 
the account can be accessed for PIN debit transactions as will be further 
described below in connection with the physical card embodiment of the 
present invention (see Figure 4) 

The establishment of a separate IPA/VPL account 230 for 
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electronic credits and payments is preferable from a user's point of view in 
order to provide a separate accounting from the user's normal DDA. As 
with its regular accounts, a transaction history for the IPA 230 is archived. 
As the IPA account 230 is not necessarily interest bearing, it is envisioned 
that the user would accordingly only fund small amounts into this account 
in order to cover potential on-line purchases. The user can set up periodic 
(e.g., weekly) automatic funding of the IPA account 230. In an alternative 
embodiment of the present invention, the user's payments in accordance 
with the present invention may be made directly against a normal DDA 
account. 

The IPA 230 or VPL 235 accounts can have physical 
companion card for physical, in person, purchases and withdrawals as will 
be further described below with respect to Figure 4. Each of the IPA 230 
and VPL 235 accounts allow physical access via ATM's or merchant card 
readers for PIN debit transactions. 

One of the most significant features of the present invention 
is the use of the existing EFT networks 270. Although these networks 270 
have provided secure transfer of funds for years, the use of these networks 
in accordance with the present invention is heretofore unheard of. In the 
use of the EFT network, the present invention provides real time credit. 
This is contrasted to the prior art debit message methods in which the only 
semblance of credit provided in a reversal of a prior debit transaction (e.g., 
credit cards). The EFT networks 270 are used to effect IPA transactions, 
fulfill IPA reporting functionality, and can be used to fund the IPA 230. As 
well as supporting the transmission of real time credit messages, the EFT 
network 270 transmits messages containing special transaction codes and 
account and bank number structures (addresses) used to uniquely identify 
IPA transactions. Furthermore, the EFT network 270 can be used to verify 
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the existence and validity of destination accounts as further described 
below. 

As described above, similar to an IPA account 230, the 
Virtual Personal Lockbox (VPL) 235 is a limited function account. While 

5 an IPA 230 can be accessed electronically for outgoing payment 

transactions, a VPL 230 is constructed with EFT network "receive only" 
functionality. This feature of a VPL account (or a VPL address for a dual 
access IPA/VPL account) provides a merchant (or other party) to receive 
electronic credits (e.g., payments) through the EFT 270. In this manner a 

0 VPL 235 is a secure address that can be provided to the public as a means 

of receiving funds. Once received by a VPL account 235, funds can then 
be manually or automatically swept by the merchant's bank 275 to one of 
the owner's other accounts 280 (e.g., a DDA or cash concentration account 
280). This sweep can be performed once a day, or more or less than once a 

5 day as dictated by the needs and objectives of the VPL user. 

Like an IPA account 230, the VPL 235 can have a physical 
companion card for physical, in person, purchases and withdrawals. The 
VPL 235 can allow physical access via ATM's or merchant card readers 
for a PIN debit transaction using a user only access (address) for debit 

0 transactions from the VPL 235. Although providing the general function of 

an account (to hold funds), it must be repeated that the basic functionality 
of a VPL 235 is distinct from the IPA account 230 functionality. The VPL 
235 is a secure lockbox into which funds can be transferred but cannot be 
taken out (except during the sweeping process or other PIN transactions 

5 described herein). 

In preferred embodiment of the present invention, VPL 
addresses for various merchants and other receivers of electronic payments 
are made available in a public directory 325 (see Figure 3). Since the 
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'receive only' address of a VPL account 235 is what is published in the 
public directory, merchants and other users of the 'receive only' VPL 235 
are alleviated of the fear of the fraud. In the preferred embodiment, the 
directory of VPL addresses 325 is maintained on an Internet accessible 
5 server or servers and accessed through a website that provides the 

capability to search and select and retrieve VPL information. 
Alternatively, the directory 325 can be accessed by PDA, kiosk or by 
phone using voice recognition or other telephony technology. The 
directory 325 can be used by the PPP enhanced Wallet 21 5 to verify the 

1 0 accuracy of a VPL address before it commits to transferring a credit 

message to the account designated in the VPL address. 

As described above, the address for an IPA 230 or VPL 235 
consists of an identification of the institution at which the account is held 
(typically six digits) and an identification of the account (typically ten to 

15 thirteen digits). For consumers (the "white pages"), the directory 325 

contains but is not limited to the VPL address, the last and first name of the 
VPL consumer, the user's Post Office address, phone and email address. 
For businesses (the "yellow pages"), the directory 325 contains but is not 
limited to the VPL address, the business name, the industry or type of 

20 business, the business' Post Office address, phone and email address. 

As briefly described above, the Account Reporter 240 is a 
portal to view the VPL account 235. The Account Reporter 240 provides 
online, real-time transaction reports, and reconciles accounts 
receivable/purchase records 250 against incoming EFT payment records 

25 245. Although primarily intended for use by merchants, much of the 

functionality of the Account Reporter 240 is incorporated in the PPP 227 
Wallet 215. The PPP 227 preferably include a base set of requirements for 
consumers, and the Account Reporter 245 would contain added features 
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required for merchants and businesses (e.g., reconciliation of purchase 
records and payment records). 

The VPL account 235 updates the Account Reporter 240 as 
payment records (credit messages) and transaction numbers are received 
5 through the EFT messaging system 270. At the same time, any purchase 

orders 250 (in the form of a record) and payment confirmations (see below) 
are passed to the Account Reporter 240 from merchant and billing web 
sites. As seen in Figure 2, the Account Reporter 240 is also capable of 
receiving purchase confirmations 244 from the PPP 227. Purchase 

1 0 confirmations 244 and payment records 245 are retrievable, in real-time, 

from the Account Reporter 240. Account Reporter 240 users are able to 
view their records with respect to their VPL accounts 235 on the Internet. 
Although only one VPL account 235 has been illustrated in Figure 2, it is 
understood that a merchant is able to simultaneously maintain several 

15 VPLs 235. Each of these VPLs 235 is capable of being accessed and 

viewed by the single Account Reporter 240, much like a consumer is able 
to associate several IPA/VPL accounts with its PPP 227 and is able to view 
these accounts using the PPP 227. 

In addition to the functionality described above with respect 

20 to the base features of the Account Reporter 240 (storing, reviewing, 

sorting transaction histories), a merchant embodiment of Account Reporter 
240 includes additional functionality. A first of the additional functions 
provided by the merchant Account Reporter 240 is its reconciling 
capability that matches purchase requests 250 generated by the merchant's 

25 website 255 with shopper's purchase confirmations 244 and the EFT 

payment records 245. Any items that do not match are flagged by the 
Account Reporter 240 as exceptions for review. The merchant Account 
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Reporter 240 further provides for identification (ID) and password security, 
offering varying levels of access authority to the users. 

Additionally, the merchant Account Reporter 240 
automatically updates the merchant's accounts receivable, inventory & 
5 fulfillment files. As a further extension, Account Reporter 240 also has 

fulfillment service capabilities whereby information from a merchant's 
website 255 is consolidated and communicated to a warehouse to initiate 
product shipment 260, as well as linked to United Parcel Service (UPS™), 
Federal Express (FedEx™), or other shipping services for shipping 

10 execution. The Account Reporter 240 contains essential customer service 

tools such as the ability retrieve/review electronic purchase 
. orders/payments real time, and in turn the ability to email or autofax copies 
of such directly to customers. The Account Reporter 240 further provides 
data mining tools that collect statistics on buyer/shopper behavior, track 

15 seasonal and regional buyer/shopper trends, and track other key 

demographics. Based on these statistics, merchants can issue focused, 
customized electronic coupons through their Account Reporter 240. 

In one embodiment of the present invention, the user of an 
IPA account 230 can specify whether or not the credits it pushes from the 

20 IPA includes any identification information at all (e.g., account number, 

name ...) One of the features of the electronic credit pushes of the present 
invention is that the credit pushes can be made completely anonymously, 
with the recipient of the credit having no way to determine from where the 
credit originated. The recipient of the credit is able to match the received 

25 credit with a proposed purchase using a transaction ID that is contained in 

the EFT credit push. In the Internet shopping embodiment described 
below, the Internet merchant provides the buyer with the transaction ID and 
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the buyer includes the transaction ID in the EFT credit message sent to the 
Internet Merchant's VPL account. 

If the user is less concerned with privacy, the user can 
include a partial or complete identification of itself in the credit push. If 
5 the credit push received by a VPL 235 does contain some identification 

information, the Account Reporter 240 can be configured such that the 
identities of individual buyers will not be available to the Account Reporter 
240 without the prior consent of the user who initiated the credit to the 
VPL 235. For consumers, the Account Reporter 240 appears as a seamless 

10 part of the PPP 227, while for merchants and businesses, the Account 

Reporter 240 appears as a separate utility. 

Merchant Web sites 255 are well known to those skilled in 
the art. Merchant Web sites 255 typically include code (such as HTML, 
XML, or ECML) for getting transaction BIN statements (payment 

15 messages) to the Wallet 215. As further described below these payment 

messages typically contain the merchant's VPL 235 address which includes 
the address of the merchant's bank 275. The payment messages enable the 
consumer to push a credit from its IPA account 230 through the EFT 
system 270 to the VPL account 235. Merchant's websites 255 can provide 

20 a hotlink on the shopping site 255 that goes directly to shopper's PPP 

enhanced Wallet 215. 

Having described the structural elements of the present 
invention, the following discussion illustrates an embodiment of the present 
invention related to Internet shopping. As in all of the remaining Figures 

25 2-9, the method steps are illustrated in the Figures in small circles next to 

the structural element most closely related to the action being performed. 
In this embodiment, the consumer (user) initiates the process in step 2A by 
logging onto the Internet, launching the Browser 210 and selecting the PPP 
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enhanced Wallet 215 icon from Browser 210 toolbar. The PPP enhanced 
Wallet 215 does not have to activated until the user actually wishes to buy 
something, but the PPP enhanced Wallet 215 could also contain lists of 
links to a user's favorite shopping sites (or billing sites as is further 
5 described below). 

In step 2B, the user completes a certification procedure 205 
in order to correctly identify him or herself to the PPP enhanced Wallet 
215. Typically the certification process involved the user keying in the 
user's ID and password on the keyboard associated with the workstation 

10 200. The user is thus authenticated and has access to their PPP enhanced 

Wallet 215. In step 2C, the user is then presented with balance information 
with respect the IPA accounts 230 associated with the PPP enhanced 
Wallet 215 and can select from several options. In a preferred embodiment 
the options presented to the user include: Shop on the Web; Pay Anyone 

15 (see Figures 3 and 5); Fund Accounts (see Figure 9); Pay Bills (see Figures 

6-8); and View Account Activity. 

Assuming the user has selected the Shop on the Web option 
in step 2D, the Browser 210 could be initially directed to special website 
list of approved merchants (which can also contain the VPL addresses for 

20 such merchants). Alternatively, the user is free to navigate the Internet to 

the merchant web site of their choice. In step 2E, the user has found a 
website 255 of a particular merchant and more specifically has found and 
selected an item for purchase from merchant web site 255. Since the PPP 
enhanced Wallet 215 is active, the merchant's site 255 recognizes user as a 

25 PPP enhanced Wallet 215 customer. In response to this recognition, all of 

the purchase fields (shipping address, name, etc.) required by the merchant 
site 255 are automatically populated from the PPP enhanced Wallet 215 as 
described above. Alternatively, the user can sign on to their PPP enhanced 
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Wallet215 after the user has found an item at a website for purchase. The 
user can either invoke the PPP enhanced Wallet 215 by clicking on an icon 
embedded directly into the merchant's web page 255, or by clicking on a 
wallet button on the Browser 210 toolbar. 

In step 2F, the merchant site 255 generates and transmits to 
the user a bill payment message containing information with respect to the 
prospective purchase. The information provided by the website 255 in the 
bill payment message includes but is not limited to the following data: 
Merchant BIN; Merchant Account #; Transaction ID; and the Dollar 
Amount of the transaction. In step 2G the bill payment message is received 
by the Wallet 215 window. A window displays the bill payment message 
for review by the user. If the user changes his or her mind, the user can 
select a button on the window entitled Decline Purchase. If the user does 
want to complete the purchase, a Purchase Item button is selected. 
Although described above with respect to a single item, it is clear that the 
above process equally applies the shopping cart method employed by most 
merchant sites 255. In the shopping cart method, after the customer has 
selected a number of items to purchase, the merchant site 255 totals the 
items and transmits a consolidated payment message to the PPP enhanced 
Wallet 215 in step 2F. 

If the user has selected to purchase the item pursuant to the 
bill payment message from the merchant site 255, the PPP portion 227 of 
the PPP enhanced Wallet 215 in step 2H first verifies the user's balance in 
the primary IPA account 230 associated with the PPP enhanced Wallet 215. 
If there are insufficient funds in the IPA account 230, the user is asked if 
he/she would like to transfer funds from another account into the IPA 
account. Using online banking procedures, the PPP enhanced Wallet 215 
is able to transfer funds from any account accessible by the PPP enhanced 
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Wallet 215 into the IPA account 230. If there are sufficient funds in the 
IP A account 23 5 , the PPP 227 generates a payment authorization message 
for transmission to the bank 220. The payment authorization message 225 
contains the above described payee information (merchant VPL account 
5 and bank address) and can also contain a user defined memo field for entry 

of any information desired by the user (e.g., "payment for new mystery 
book"). 

In addition to generating and transmitting the payment 
authorization 225, the PPP 227 transmits a purchase acknowledgement 

10 directly to the merchant's website 255. Typically, in response to this 

purchase acknowledgement from the user's PPP 227, the merchant's 
website 255 creates a purchase record 250 in a database (not shown) for 
future use in reconciling with the actual payment confirmation 244 and/or 
payment record 245. As illustrated in Figure 2, the PPP 227 also send a 

15 payment confirmation 244 either to the website 255, or the merchant's 

Account Reporter 240. In the preferred embodiment, the payment 
confirmation 244 is in the form of an electronic message (e.g., an E-mail) 
to the Account Reporter 240. The payment confirmation 244 can be sent 
either before or after the PPP 227 has actually transmitted the payment 

20 authorization 225 to its bank 220, without any confirmation from the bank 

220 that the payment was actually transmitted via the EFT network 270. 
Alternatively, the PPP 227 can wait until it has received confirmation from 
the bank 220 that the EFT credit message was actually sent through the 
EFT network 270. 

25 In the preferred embodiment the banks 220, 275 which 

maintain IPA 230 and VPL accounts 235 also maintain the above described 
database that is used as a centralized record keeping archive in order to 
feed and retrieve transaction data. Such transaction data includes but is not 
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limited to payment authorizations 225, payment confirmations, and the 
records required for the Account Reporter 240 including EFT transaction 
data. 

In addition to the payment acknowledgment sent to the 
merchant's website 255, and the payment confirmation sent to the Account 
Reporter 240, the PPP 227 transmits the payment authorization 225 to the 
user's IPA account 230 to effectuate the actual transference of the funds 
from the user's account 230 to the merchant's account 235 via an EFT 
credit message on the EFT system 270. The consumer's bank 220 will 
require some form of authentication of the payment authorization from the 
PPP 227. This authentication can be in the form of a software certification, 
an encrypted PIN, or the mother's maiden name of the consumer. Once the 
bank 220 has authenticated that the message truly originated from the 
consumer, the bank 220 can then fulfill the payment authorization 225. 

Upon receipt of this authorization for payment 225, in step 
21, the user's bank 220 debits the user's IPA account 230 to generate an 
EFT credit message in the amount of the authorized payment. As 
described above, the EFT credit message is completely different from 
traditional EFT messages that are debits or the reversals of debits. Once 
generated, the EFT credit message is transferred to the merchant's VPL 
account 235 via the ATM switch 270. Although the credit instruction is 
illustrated in Figure 2 as being processed directly by the accounts 230 and 
235, it is appreciated that the records are actually processed by the 
messaging systems and processors of the user's bank 220, the merchant's 
bank 275 and the EFT network 270. The EFT credit message is essentially 
a guarantee of payment from the user's bank 220 (the funds being debited 
from the user's account 230) to the merchant's bank 275 (the funds being 
credited to the merchant's account 235). Settlement between banks 220 
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and 275 typically occurs once a day with respect to all outstanding credits 
and debits between the banks 220, 275, although the cash is available from 
the VPL account 235 upon receipt of the EFT credit message. 

After the EFT credit message has been received by 
5 merchant's VPL 235, the receipt of the credit is detected by the merchant's 

Account Reporter 245 (step 2 J). In response to the detection of the credit, 
the Account Reporter 240 preferably generates and stores a payment record 
245 in the same database in which the purchase record 250 was stored in 
step 2H described above. Although only a single payment record 245 has 

10 been illustrated in Figure 2, it is appreciated that two payment records 245 

can exist for a single payment transaction. The first payment record 245 
can be generated upon the receipt of the payment confirmation 244 from 
the user's PPP 227. The second payment record 245 can be generated upon 
the actual receipt of the EFT credit over the EFT system 270. 

15 Once the payment record 245 has been stored, it can be 

reconciled by the Account Reporter 240 against the merchant's purchase 
record 250 (step 2K). In this manner, the accounting loop in the 
merchant's system can be closed, with the matching of the merchant's 
invoice (the purchase record 250) with the payment (the payment record 

20 245). Alternatively, the Account Reporter 240 can reconcile the above 

described two payment records (one generated from the payment 
confirmation and one generated from the EFT credit message) against the 
purchase record 250. With Account Reporter 240, a merchant has a 
product that allows for secure transaction fulfillment, reconcilement ability, 

25 record-keeping and archive possibilities. Once the financial loop has been 

closed with the receipt of the payment record 245 by the merchant, the 
merchant can confidently ship the goods 260 to the consumer in step 2L. 
Shipment of the goods can entail physical shipment of a physical good, or 
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electronic transmission of a digital good such as a music file. 

In fulfillment of the guarantee established by the EFT credit 
message, funds are settled once a day in step 2M between user's bank 220 
and the merchant's bank 275 through the EFT switch 270. Typically, 
hundreds or thousands of such payments occur back and forth between 
bank 220 and bank 275 during the day and for efficiency purposes, the 
actual net funds due from one bank to the other are only transferred once 
per day. For example, one bank 220 might have guaranteed $10,000 in 
EFT credit messages from one hundred of its customers to the other bank 
275. On the same day the other bank 275 might have guaranteed $12,000 
in EFT credits from fifty of its customers to the other bank 220. At the end 
of the day, bank 275 only sends the difference, $2,000, to bank 220 and 
each of the banks 220, 275 ensure that the proper accounts in its own bank 
are debited and credited for the payments. As can be readily appreciated 
each bank performs this end of day settlement with hundreds of other 
banks, as is presently done with the current ATM system 270 transfer of 
funds. Again on a daily basis, the funds received into the merchant's VPL 
account 235 are swept by an automatic process into the merchant's cash 
concentration account 280, which can be a DDA or IPA account. 

As is readily appreciated from the above description, the PPP 
enhanced Wallet 215 and the Virtual Private Lockbox (VPL) 235 
significantly enhances the consumer and merchant experience when used 
for web shopping. The present invention completely solves one of the 
biggest problems of the prior art, the hesitancy of a consumer to provide 
financial account information over the Internet. Rather than the merchant 
"pulling" in the consumers account information and requiring 
authentication of the consumer, the PPP enhanced Wallet 215 "pushes" an 
EFT credit message to the merchant's Virtual Private Lockbox, without the 
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merchant ever obtaining the consumers account information. This 
transaction is virtually instantaneous, provides privacy, security, and 
convenience to the consumer — and guarantees funding, provides 
reconcilement, and supplies archival records to the merchant. 
5 With respect to authentication, because the consumer is 

pushing the payment to merchants or other entities or individuals, rather 
than the merchants pulling payments from consumer accounts, the 
consumers do not need to authenticate themselves to the merchant. Rather, 
the consumers authenticate themselves to their own bank 220, which then 
10 executes the EFT credit payment to the merchant's VPL account 235. 

This method of the present invention is quite attractive to 
consumers because they can pay any merchant regardless of the existence 
of a pre-existing relationship with that individual or entity. The transaction 
can furthermore be conducted from anywhere there is access to the 
15 Internet. The IP A account 230 can be used and managed through the 

consumer's PC, a web enabled ATM, by phone or by any other web 
enabled device. The present Internet shopping payment method is 
extremely easy for online banking customers to adopt. The method allows 
consumers to conduct online shopping without having to provide any 
20 personal confidential financial information to unknown merchants. The 

method allows consumers to conduct these financial transactions solely 
with her or his own financial institution. 

With respect to merchants that are paid by the method of the 
present invention, there are several advantages. This method opens up a 
25 universe of buyers/payors who do not have access to or the desire to use 

credit or debit cards online. Very little effort is required on the part of a 
merchant which only has to publish its bank 275 and VPL deposit only 
account 235 information on its web site 255 or other public directory (see 
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335 in Figure 3). If a merchant has been using traditional credit card 
methods, the present invention provides the merchant with significant 
savings in credit card processing, repudiation costs, fraud loss, and 
chargeback costs. The present invention also provides the merchant with 
the ability to economically accept micropayments. 

Figure 3 illustrates a second embodiment of the present 
invention in which the structures described above can be used by a user to 
pay anyone. The PPP 227 of the present invention provides the user with 
tremendous flexibility. Anyone with using a PPP 227 can conveniently 
send funds to anyone else with an IPA/VPL account. This funds transfer is 
instantaneous and at no cost to the consumer, and is conducted in a secure 
environment. 

As described above with respect to the Internet shopping 
model illustrated in Figure 2, in the pay anyone model of Figure 3, in steps 
3A-3C, the user logs onto the Internet, launches its browser (not shown in 
Figure 3) and launches the Wallet 215. In the embodiment of Figure 3, the 
Wallet 215 is a traditional Wallet with the appropriate interface to the the 
PPP 227. When the user wants to activate the PPP 227, the user is required 
to key in its user ID and password, by which the user is then authenticated 
and has access to their the accounts 230 associated with the PPP 227. The 
user is then presented with its account balance information and can select 
from several options including Shop on the Web, Pay Anyone, Pay Bills, 
Pay Anyone, Fund Wallet, Review Account Activity, Edit Wallet 
information, or Go to Customer Service. 

In the present embodiment illustrated in Figure 3, the user 
selects the Pay Anyone option from the menu and the user is presented 
with several options in the Pay Anyone menu screen in step 3D. These 
options include: manually keying in the payee's VPL number; selecting a 
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prior payee from a drop down menu; Add/Remove/Edit a payee from drop 
down menu; and the option to go to an online directory (325) of VPL 
numbers of various payees. In the particular embodiment illustrated in 
Figure 3, the user keys in (or selects) the payee's VPL address, the dollar 
5 amount of the payment, and a description of the reason for the payment, the 

description being optional. 

In step 3E, the above described payment information is 
transmitted to payee's Wallet 3 1 5 (or PPP 227, not illustrated). The 
payee's Wallet 315 verifies the VPL number specified by the user and 

10 provides an authorization to make the payment. In step 3F, the payee's 

Wallet 315 confirms that the information is correct and transmits to the 
user (payor) a payment message with the following data: Payee BIN; Payee 
Account #; Transaction ID; the dollar amount of the payment; and an 
optional description. In step 3G, upon receipt of the payment message, the 

15 user reviews the message and selects "OK to Pay". Step 3D through 3G 

are an optional process since the PPP 227 can unilaterally initiate the push 
of an EFT credit message without ever having contacted the receiver of the 
credit. In such a blind push of a credit it is recommended that the PPP 227 
consult an online directory 325 to verify the accuracy of the address to 

20 which the EFT credit message is to be sent. 

In step 3H, the user's PPP 227 sends the payment 
authorization 225 to the user's IPA account 230. In parallel, the user's PPP 
227 transmits a payment confirmation of the expected payment to the 
payee's Wallet 315 or Account Reporter 340 which creates an expected 

25 payment record 350. The user's PPP 227 goes through the certification as 

described above in order for the user's bank 220 to properly identify the 
payment authorization 225. In step 31, the EFT credit message is passed 
from user's IPA account 230 to the payee's VPL 335 via the ATM switch 
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270. As described above, the payee's VPL 335 may actually be the receive 
only address of an IPA account maintained by the payee. 

In an alternative embodiment, a verification message is first 
sent though the EFT network 270 to the destination account 335. The 
purpose of this verification message is to verify the existence and identity 
of the VPL account 335. In response to the receipt of the verification 
message (assuming the VPL address was accurate and the message was 
received), the VPL account sends back a response message that includes a 
text description of the owner/user of the VPL account 335. This response 
message is then displayed to the user via the PPP 227 so that the user can 
verify that the account 335 to which it is about to send a credit is actually 
owned/used by the party to which the user intend to send the credit. 

This verification procedure can be used in the Internet 
shopping model described above with respect to Figure 2. In fact, the 
verification procedure is useful in thwarting any attempts at hacking of the 
VPL address transmitted (step 3F in Figure 3 and step 2F in Figure 2) via 
the Internet in the payment message from the merchant (255 in Figure 2) or 
other payee (represented by Wallet 315 in Figure 3). For example, if the 
payment message originated from Amazon™ and included Amazon's VPL 
335 address, the verification procedure described above through the secure 
EFT 270 network would inform the user that the owner of the VPL 335 
was truly Amazon. If a miscreant (e.g., Joe Hacker) had intercepted the 
payment message and inserted its own VPL address, the response message 
in accordance with the verification procedure will visually inform the user 
that the VPL address to which it will send the credit is owned by Joe 
Hacker. At this point the user can abandon the transmission of the EFT 
credit and try and identify Amazon's true VPL address. 

In an alternative verification procedure, the PPP 227 can echo 
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back to the sender of the payment message (merchant 255 in Figure 2 or 
Wallet 3 15 in Figure 3), the VPL address contained in the payment 
message. The sender can then verify for itself that the user has the correct 
VPL address to which to send the credit. This alternative verification 
5 process requires the hacker to intercept and alter two separate messages. 

Although better than no verification, the alternative procedure is still not as 
attractive as the EFT network 270 verification as it occurs in the unsecured 
Internet space. 

Returning to Figure 3, in response to the receipt of the EFT 

10 credit message by the payee's VPL 335, a payment record 345 is generated 

(step 3J). Upon the receipt of the payment record 345, the payee's Wallet 
3 1 5 or Account Reporter 340 in step 3K is able to reconcile the expected 
payment record 350 against the actual payment record 345. Further in 
response to the receipt of the EFT credit message, the payee bank 375 

15 credits the payee's VPL account 335 and the payee now has immediate use 

of funds. These funds can in turn be used for web shopping, bill payment, 
pay anyone, or can be withdrawn at an ATM using the card feature 
described below. 

In concluding the pay anyone process, as with the 

20 embodiment illustrated in Figure 2, funds are settled once a day between 

the user's bank 220 and the payee's bank 375 (step 3M), and the funds can 
be swept into the payee's DDA or other IPA account 380 (step 3N). 

The pay anyone process described above is a very attractive 
payment method for consumers. For example, the consumer might be 

25 responding to a classified advertisement (electronic or traditional paper) or 

purchasing an item or a service through an electronic auction site such as 
eBay™. In either of these cases, the consumer can obtain the payee f s VPL 
account 335 information (e.g., BIN, account number ...) in a variety of 
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ways. In one method, the consumer obtains this information electronically 
from the service where it contacted the individual (e.g., through eBay™). 
Alternatively, the consumer can obtain the necessary destination account 
information through offline methods such as the traditional paper classified 
5 advertisement or through an Email which has been "pushed" to the 

consumer by the potential payee. The potential payee is protected using 
these methods since the VPL account 335 is a receive only account and no 
one can access the account to fraudulently withdraw money from the 
account. The user can furthermore obtain the payee information from the 

10 online directory 325, from a pull down menu on the Wallet 215 or by 

keying in the information manually. 

Figure 4 illustrates an embodiment of the present invention 
involving a physical card associated with a VPL or IPA account. In this 
embodiment, the physical cards are linked to IPA or VPL accounts 

15 containing an initially established pre-set amount of cash. The card is 

issued to the IPA or VPL account user in order for the user to access the 
IPA or VPL account in the physical world. Furthermore, the cards can be 
purchased at vending machines placed in convenient e-commerce locations 
or other distribution outlets such as at the mall, convenience stores, or 

20 banks. In a preferred embodiment, when a user establishes a traditional 

Wallet 215, the user is offered an option to establish an IPA/VPL account, 
receive a PPP enhanced Wallet 215, and receive a physical card associated 
with the IPA/VPL account. Upon selecting this option, the card is mailed 
to the IPA/VPL user. 

25 In the vending machine embodiment, the card is purchased 

from the vending machine with pre-funded with set increments of currency. 
These increments are associated to specific account number ranges, and are 
linked to IPA/VPL accounts. In one embodiment, the physical card is pre- 
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activated (i.e., ready for immediate use). Alternatively, the card can be 
automatically activated upon its disbursement from the machine, or by the 
consumer making a toll-free call to a customer service line, or activated 
upon the user's first use of the card. The purchase of a card at a vending 
5 machine establishes a IPA/VPL account for the purchaser. As an 

alternative to the preset association of a card to an account and dollar 
amount, the association of the card to the account and the funding of the 
account can be accomplished dynamically as the user is purchasing the 
card. 

10 Once purchased, the cards can be accepted at ATM's and 

merchants that are outfitted with card readers. Since the cards are PIN 
protected, they are safer than cash. The card has the IPA/VPL account 
number as well as a PIN. The PIN is printed on a sticker affixed to the 
back of the card when the card is issued. The account number is stored on 

1 5 the magnetic stripe on the back of the card. The VPL portion of the 

account associated with the card can receive EFT credits as described 
above and can funded from other accounts as also described above. The 
card can be used to withdraw funds at an ATM and make purchases from 
any merchants that accept debit cards. 

20 For card purchased by someone who did not previously have 

a IPA account, in order to subsequently use EFT credit pushes as described 
above, the card owner will be required to establish an IPA account with the 
sponsor of the card. For example, if the sponsor was a bank, the user signs 
onto bank's website, the new card owner keys in the card number and PIN 

25 to synchronize the VPL with a newly created IPA account for the user. 

This synchronization will add the IPA account to the card link. The user 
can then specify against which account portion, IPA or VPL, debits will be 
made when using the card. The user will also be asked to indicate whether 
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any funds received by the VPL will be swept to the newly created IPA or to 
an existing DDA account. 

One specific embodiment purchasing and using a physical 
card is illustrated in Figure 4. In step 4A, the purchaser selects a card from 
either a vending machine 400 or a vending enabled ATM (not shown) or 
other distribution outlet. In a preferred embodiment, cards can be 
purchased for as little as a $1, or in larger ATM-like increments. After 
making a selection, the purchaser is prompted to pay for the card. Several 
purchasing options are available, including cash, debit cards and credit 
cards. 

In step 4B the card is disbursed from the machine 400 with a 
pre-assigned PIN as well as instructions for using the card. The card is 
either pre-activated or alternatively, the dispensing machine 400 sends an 
activation message to the card sponsor upon its purchase, or the card is 
activated upon its first use, or the user can phone in to activate the card. 
The distribution outlet (e.g., vending machine) also provides the purchaser 
with a printed receipt that can be used in the event that the user loses the 
physical card. 

With the card in hand, the user is able to withdraw funds 
from the account associated with the card or making store purchases using 
the card. In step 4C, the card owner inserts the card into an ATM machine 
430 or a merchant card reader at a merchant's Point Of Sale Location. The 
user then keys in the PIN number to identify her or himself as the proper 
owner of the card. In step 4D the merchant's card reader, which is 
connected to the EFT network 270, transmits a debit message through the 
EFT switch 270 to the sponsoring bank 410. 

As similarly depicted in Figure 2, the debit message is seen 
as being received directly by the user's VPL account 420, but in practice, it 
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is realized that all EFT messaging occurs through the systems of the bank 
410. The message is transmitted to the bank 410 as an online PIN debit 
transaction against the user's VPL account 420. Upon verification that 
there are sufficient funds available in the VPL account 420 associated with 
5 the requesting card, the transaction is authorized by the VPL sponsor 410 

and the funds are deducted from the balance in the VPL account 420. In 
step 4E, the authorization message is transmitted back to the ATM or POS 
430 through the same EFT network 270 and the funds are released to the 
card owner (in the case of an ATM withdrawal) or credited to the merchant 

10 (store purchase) in step 4F. 

Figure 5 illustrates an embodiment of the present invention in 
which the user can instantly transmit funds to anyone, specifically some 
one with a card and VPL account as described above. The payee (recipient 
of the funds) can withdraw the funds via an ATM through the use of the 

1 5 physical card, which the payee can either purchase at a vending machine or 

receive by mail when establishing an account, as described above. As with 
all of the embodiments of the present invention, this pay anyone feature 
ensures that the transaction is conducted in a secure environment. 

As described above with respect to the embodiments of 

20 Figures 2 and 3, in the pay anyone method of Figure 5, in steps 5A-5C, the 

user logs onto the Internet, launches its browser (not shown in Figure 5) 
and launches its PPP 227. As readily appreciated in Figure 5, a traditional 
Wallet 215 is not required to practice the essential features of the present 
invention, as these features are enabled by the PPP 227. In Figure 5, the 

25 PPP 227 operated as a stand alone component. The PPP 227 requires that 

the user keys in its user ID and password, by which the user is then 
authenticated and has access to their PPP 227. The user is then presented 
with its account balance information and can select from several options 
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including Shop on the Web, Pay Anyone, Pay Bills, Fund Wallet, and 
Check Account Activity. In the present embodiment illustrated in Figure 5, 
the user in step 5D selects the Pay Anyone option from the menu and is 
prompted for the VPL number of the account associated with the card. The 
procedure set forth above with respect to the pay anyone method of Figure 
3 is then followed. 

In step 5E, user's PPP 227 generates a payment authorization 
with the following data: Payee BIN; Payee VPL number (card number); 
Transaction ID; and dollar amount. After reviewing the information, the 
user then selects "OK to Pay" on the workstation 200 screen (e.g., PC, 
PDA ...). In step 5F, the user's PPP 227 verifies the balance in the IPA 
account 230 and passes the payment authorization to IPA 230 if there are 
sufficient funds in the account 230 to cover the transaction. As an optional 
step, the payee information is validated (i.e., the VPL account associated 
with the card is valid and is owned by the intended payee). In step 5G, 
the EFT credit message is passed via the ATM switch 270 from user's bank 
220 (IPA account 230) to the payee's bank 575 (VPL account 535). 

The payee can withdraw the funds via an ATM 500 through 
the use of the physical card as described above. When the withdrawal is 
requested, a debit payment message is transmitted in step 5H from the 
payee's VPL account 535 to the ATM 500 provider bank (not shown). The 
payee now has immediate use of funds, and the withdrawal is made in step 
51. Alternatively, the payee can use the card at a POS using the above 
described PIN debit procedure. As with the previous embodiments, funds 
are settled once a day between the payor's bank 220, the VPL user's bank 
575, and the ATM 500 provider bank. 

The present embodiment is well suited for many different 
situations. For example, if a parent has a son or daughter away at college, 
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the parent has provided the child with a card and associated VPL account 
535, and is able to transfer funds to the child's account 535 in a simple, 
quick and cost efficient manner by use of the present invention. Those 
skilled in the art will appreciate that the above embodiment can be used by 
5 a customer of the bank to transfer funds to anyone, such as the customer's 

gardener or a child at college as described above. 

Figures 6, 7 and 8 illustrate three different bill paying 
embodiments according to the present invention. Figure 6 depicts a direct 
bill paying embodiment, Figure 7 describes bill payment including a 

10 service provider performing consolidation, and Figure 8 explains a bill 

payment method in which the customer performs the consolidation. In 
Figure 6, the direct method, a biller establishes an e-billing capability on its 
own web site 255. Once enrolled in the service, the customer receives an e- 
mail notification that a bill is available for payment at the biller' s web site 

15 255. Alternatively, the customer can receive a traditional paper bill. The 

customer launches its Wallet 215, Browser 210 and PPP 227 and then 
accesses the biller' s web site 255. A payment is then eventually 
transmitted from the PPP 227 to the biller' s Virtual Private Lockbox 235. 
As in all of the embodiments of the present invention, the transaction is 

20 secure, protects the customer's privacy, and provides the biller with 

guaranteed funding, reconcilement, and archival records. 

As is illustrated in Figure 6, the biller/merchant first 
establishes an e-billing relationship with its customer. One way in which 
the merchant might do so is to advertise its e-billing service via e-mail, 

25 mail, or on the Internet. In step 6A, it is assumed the user has enrolled in 

the e-bill service at biller's web site 255 and is receiving monthly Email 
notification when bills are available. As previously described, in step 6B 
the user logs onto the Internet, launches its browser 210, Wallet 215 and 
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PPP 227 and is presented with the various menu options. In step 6C, the 
user selects the "Pay Bills" option and is given several options in the Pay 
Bills menu screen including "Pay Bills" and "Edit Billing information". 
Selecting the "Pay Bills" choice, the user navigates to the biller's web site 
255. It must be recalled that the Wallet 215 already contains user's billing 
info. 

Since web Wallet 215 is active, biller's website 255 
recognizes the user as a Wallet 215 customer. In addition, the biller's 
website in step 6D verifies that customer has an established e-billing 
relationship. In step 6E, the biller's site 255 generates and transmits to the 
user a bill payment message that includes the following data: Biller's BIN; 
Biller's Account number; Transaction ID; and the dollar amount of the bill 
to be paid. In step 6F, the bill payment message is received by the Wallet 
215 window and is displayed for review by the user. The user has several 
options including at least the choice to edit the bill (e.g., the amount to be 
paid) or the option to pay the bill as presented. 

If the user selects the "pay the bill" option, the PPP 227 
verifies the user's balance in its IPA account 230 and passes the payment 
authorization 225 to the IPA account 230 while simultaneously 
transmitting a payment confirmation 244 to the biller/merchant's website 
255 or VPL Reporter 240 (step 6G). As alternatively shown, the PPP 227 
can transmit the payment confirmation 244 to the biller/merchant's website 
255 or VPL Reporter 240. In response to the receipt of the payment 
authorization 225, the EFT credit message is passed from the user's IPA 
account 230 to the biller's VPL account 235 via the ATM switch 270 (step 
6H). A bill payment record 245 is then generated and stored by the biller's 
Account Reporter 240 in response to the receipt of the credit message from 
the EFT network 270. 
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In step 6J, upon generation of the payment record 245 which 
reflects the receipt of the funds to settle the bill, the payment record 245 is 
reconciled against the biller's accounts receivable files 600. As previously 
described, with the VPL account 235 and the Account Reporter 240, a 
billing merchant can execute secure transaction fulfilment, reconcile all its 
accounts, while securely archiving all its records for later, simple retrieval. 
As described above with respect to other embodiments, funds are settled 
once a day between user's bank 220 and the biller's bank 275 (step 6K). 
The funds can be swept to the biller's DDA or cash concentration account 
280 (step 6L). 

Figure 7 depicts a further bill payment method involving 
service provider consolidator. This bill payment method is similar to the 
first illustrated in Figure 6, however in this method a central service 
provider consolidates e-bills from many different billers 700. The service 
provider's site 755 enables a customer to review and pay bills with respect 
to several if not all of its billers (e.g., electric bill, phone bill, mortgage ...). 
The service provider is seamlessly outfitted with an archival capability, so 
that customers can review their bill payment history. The PPP 227 and IPA 
230 once again provides the consumer with privacy, security and 
convenience while the VPL provides the service provider (and its 
customers, the biller/merchants) with guaranteed funding, reconcilement 
and archival records. 

In step 7A, the user enrolls in the e-bill service at web site 
755 of the Customer Service Provider (CSP). The e-billing relationship 
between the CSP and the user is established either directly in response to 
advertising by the CSP or though the billers 700 (customers of the CSP) 
advertising the services of the CSP to the users (who are customers of the 
billers). While enrolling (or at a later time) the user selects which bills it 
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wishes to receive and pay electronically through the CSP's service. The 
CSP can offer an archive service to billers 700 in order to store transaction 
history as well as providing a customer service unit to resolve transaction 
inquiries. 

5 After enrollment, the user then begins to receive monthly 

email notification when bills are available from the billers 700 chosen by 
the user. The e-bill can be sent to the user either by the CSP or directly 
from the biller 700 to the user. In this second method, the biller must 
provide the CSP with an accounts payable file reflecting the e-bills it sent 

10 out, in order for the CSP to perform the below described reconciliation 

process for the biller 700. If the CSP is the party transmitting the e-bills to 
the users, the billers 700 must provide the CSP with the billing information. 
Many types of record keeping methods are supported. The billers 700 can 
push the billing information directly to the CSP's web site, or alternatively, 

15 the electronic bills can be channeled to the CSP via Spectrum or other 

electronic Internet bill payment aggregators. 

Steps 7B and 7C are essentially the same as described above 
with respect to the direct bill paying embodiment of Figure 6. The only 
difference is that after choosing the "Pay Bills" option, instead of 

20 navigating to the biller's site directly, the user navigates to the CSP's web 

site 755. In step 7E , the user selects which bills to pay, and keys in the 
dollar amount to be paid on each bill (or selects the default, which is to pay 
the entire amount of the bill that was presented to the user). In step 7F, 
CSP site 755 generates and transmits to the user one or more bill payment 

25 messages. In one embodiment, the CSP generates a single payment 

message that includes the appropriate payment information for all of the 
bills paid during the session. In an alternative embodiment, a separate 
payment message is generated for each of the bills paid by the user. In 
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either embodiment, the message would include: the CSP's BIN; the CSP's 
VPL account number; a transaction ID (or IDs); the biller(s) name(s) and 
the dollar amount(s). 

Steps 7F through 7L are essentially the same as described 
above with respect to steps 6F through 6L of Figure 6 and the elements that 
are the same shall not be repeated. Although only a single VPL account 
735 is illustrated in Figure 7, it is appreciated that the CSP (or the billers 
directly) may maintain a VPL account 735 for each biller. Regardless of 
whether there is a single VPL 735 or several, the billers 700 themselves 
may view the contents of their receipts in the VPL 735 through the CSP's 
Account Reporter 740. In step 7J, the CSP performs the reconciliation 
process for each of its customers (i.e., the billers 700). In Step 7L, each 
biller' s receipts are swept into their respective DDA or cash concentration 
accounts 780. 

Figure 8 illustrates the third bill payment embodiment 
involving customer consolidation. In this third bill payment method, the e- 
bills 800 are delivered directly to the customer in the form of an e-mail or 
other delivery means. Each e-bill 800 contains a hotlink, which directs the 
customer to the biller's web site 855 (or to a CSPs website if the CSP 
handles the payments for the biller). When the customer activates its 
Wallet 215, the web site 855 recognizes the Wallet 215 customer and 
initiates a payment message as previously described. The customer can 
then push the payment to the biller in the same manner that a payment is 
pushed in the web shopping embodiment of Figure 2, the pay anyone 
embodiment of Figure 3, as well as the two other bill payment 
embodiments of Figures 6 and 7 using its PPP 227. As with all the 
previous embodiments, the biller once again receives the guaranteed 
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funding, reconcilement, and archival records benefits of the present 
invention. 

Figure 9 depicts a system and method for establishing and 
funding accounts associated with a PPP 227 or a PPP enhanced Wallet 215. 
As described above, a user's IPA account 230 is accessed through a PPP 
227 or a PPP enhanced Wallet 215 that can be accessed via the Internet 
900, ATM 905, telephone 910, Kiosk 915, PC 902, an interactive TV 904, 
and even a Personal Digital Assistant (PDA) 920. The primary method for 
funding the accounts (e.g., IPA account 230) linked to the PPP 227 or PPP 
enhanced Wallet 21 5 is through one of the user's other accounts (e.g., 
DDA, or credit or debit card accounts). In a preferred embodiment, the 
PPP 227 or PPP enhanced Wallet 215 can receive funds from the other 
accounts of the user using well known online banking functionality. 
Alternative funding options can be achieved through an externally 
sponsored credit card, by check or money order, or through the ACH 
network. 

Steps 9A through 9C illustrate one method by which a user 
can install a Wallet 215. As previously stated, the preferred embodiment 
includes an online banking system 962. The following example uses a 
fictional operator of the system denoted as XYZBank 965 which acts as a 
PPP enhanced Wallet provider. In step 9A, the user logs onto the Internet 
and uses its browser 210 to navigate to the XYZBank.com site 960. In step 
9B, the user selects the "Wallet" option from main menu on the 
XYZBank.com site. On the "Wallet" screen the user is presented with two 
options: "Are you an Online Banking customer?" and "Are you a Non- 
XYZBank customer? If user selects "Online Banking customer", the user 
is presented with a list of the accounts held by the user at the XYZBank 
that are supported by online banking. The user then identifies the 



WO 00/67220 



PCT/US00/12O59 



-51 - 



account(s) to which the PPP enhanced Wallet 215 will be linked. If the 
user desires, a new IPA account 230 can be established for the new PPP 
enhanced Wallet 215. If the user selects "Non-XYZBank customer", their 
PPP enhanced Wallet 215 is linked to an IPA account 230 newly set up for 
5 the customer at XYZBank 965. 

Next, in step 9C the user sets up the PPP enhanced Wallet 
215 for use by choosing "Install a Web Wallet" from the menu. The user is 
instructed that its PPP enhanced Wallet will now be installed as a button on 
the browser 210 toolbar. Once the software for the PPP enhanced Wallet 

10 215 has been installed on the user's system (e.g., the user's PC or web 

server), the user is prompted to provide some background information that 
will assist the user in making web purchases and payments. An example of 
some of the background information requested includes the user's shipping 
name address. At this point, the PPP enhanced Wallet 215 installation is 

1 5 complete and the user can perform any of the methods described above 

with respect to Figure 1-8. As previously described, using thin Wallet 
technology, the majority of the software and data associated with the PPP 
enhanced Wallet 215 resides on a server maintained by the XYZBank 965. 

Steps 9D through 9K illustrate two methods of funding the 

20 PPP enhanced Wallet 215. For customers of XYZBank 965, the primary 

method for initial and future funding of the PPP enhanced Wallet 215 is 
performed through a link between the PPP enhanced Wallet 215 and the 
Online Banking system 962 as described above. The link between the PPP 
enhanced Wallet 215 and the Online banking 962 can be transparent and 

25 the user can sign on solely to its PPP enhanced Wallet 215 and be 

seamlessly provided with the online banking 962 functionality. For initial 
funding of the PPP enhanced Wallet 215, the user selects "move funds 
to/from Wallet" from an online banking menu. The user then provides the 
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following information: the source of the funds - checking, credit card, 
savings, etc.; the dollar amount of the transfer; the funding date; and 
whether this is one time transfer or a repeat transfer. Upon completion of 
above, the account associated with the PPP enhanced Wallet 215 is funded. 
Subsequent funding of the PPP enhanced Wallet 215 associated accounts 
can be done through the PPP enhanced Wallet 215 itself or through the 
online banking system 962. In addition to funding via online banking, 
instructions can be given for funding via phone 910, ATM 905, Kiosk 915, 
or PDA 920 or interactive TV 922. 

Steps 9E through 9J illustrate a method of funding the PPP 
enhanced Wallet 215 from an external credit (e.g., cash advance from a 
credit card) or debit card, or an external DDA account (external to 
XYZBank). For the Non- XYZBank customer or an XYZBank customer 
wishing to fund the PPP enhanced Wallet 2 1 5 externally, the user in step 
9E selects "fund with a non- XYZBank account". The user then selects the 
financial merchant of the account (e.g., American Express™, VISA™, etc.) 
and keys in account number, expiration (if applicable), and the dollar 
amount of the funding transfer. The funding request is transmitted to a 
merchant acquirer 970 associated with or part of XYZBank 962. This 
account information is stored for future funding requests. 

In step 9F, the merchant acquirer 970 (such as Chase 
Merchant Services™) authorizes the funding transaction and passes the 
request through the EFT switch 270. In step 9G, the financial merchant 
980 (e.g., VISA™) receives funding request via EFT switch 270, and 
verifies the card number, expiration, and credit limit. If the funding is 
authorized by the financial merchant (step 9H) the funds are received by 
the PPP enhanced Wallet 215, more specifically, the IPA/VPL account 230 
linked to the PPP enhanced Wallet 2 1 5 (step 91). The funds settlement 
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(step 9 J) between the credit card's bank and user's bank typically occurs 
once per day. A similar process occurs when the funding is from a user's 
DDA account at another financial institution 980. In the above description 
with respect to Figure 9, it is appreciated that the procedure for establishing 
5 and funding a PPP enhanced Wallet 215 equally apply to establishing and 

funding a PPP 227 as a stand alone product. 

Although the present invention has been described in relation 
to particular embodiments thereof, many other variations and other uses 
will be apparent to those skilled in the art. It is preferred, therefore, that the 
10 present invention be limited not by the specific disclosure herein, but only 

by the gist and scope of the disclosure. 
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We claim: 

1 . A method of receiving electronic payments comprising the steps 

of: 

establishing a receive only account denoted as a Virtual Private 
Lockbox (VPL), the VPL having a first address; 
5 providing payors with the VPL first address; and 

receiving electronic payments from the payors into the VPL through 
the first address. 

2. The method as recited in claim 1 ? wherein the step of receiving 
10 the electronic payments further comprises receiving the electronic payment 

as a credit over an Electronic Funds Transfer network. 

3. The method as recited in claim 2, wherein the electronic payment 
represents a unique credit and not a reversal of a debit. 

4. The method as recited in claim 1 , further comprising the step of 
prohibiting debits from the account using the first address, whereby the 
first address can be published to facilitate the receipt of credits to the 
account. 

5. The method as recited in claim 4, further comprising the step of 
establishing a second address through which funds may be transferred out 
of the account. 

6. The method as recited in claim 5, wherein the first and second 
addresses are different. 
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7. The method as recited in claim 1, wherein the account is a bank 
account maintained at a bank. 

8. The method as recited in claim 1, wherein the account is 
maintained at an institution. 

9. The method as recited in claim 8, wherein the first address 
includes an address of the institution. 

10. The method as recited in claim 1, further comprising the step of 
publishing the first address. 

1 1 . The method as recited in claim 10, wherein step of publishing 
further comprises the step of placing the first address in a directory at an 
Internet site. 

12. The method as recited in claim 11, wherein the directory 
contains a plurality of addresses for a plurality of VPLs. 

13. The method as recited in claim 12, wherein the plurality of 
VPLs are associated with a plurality of businesses. 

14. The method as recited in claim 1, wherein the VPL is associated 
with a user, the method further comprising the step of reporting the receipt 
of the electronic payments by the VPL to the user. 

1 5. The method as recited in claim 14, wherein the user maintains 
an Internet site, the reporting step further comprising reporting the receipt 
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of the electronic payments to the Internet site. 

16. The method as recited in claim 1, further comprising the step of 
storing payment information with respect to each electronic payment 
received by the VPL. 

17. The method as recited in claim 16, further comprising the step 
of viewing the payment information. 

18. The method as recited in claim 16, wherein the payment 
information includes a source, date and amount of the electronic payment. 

19. The method as recited in claim 16, further comprising the step 
of sorting the payment information. 

20. The method as recited in claim 16, further comprising the step 
of editing the payment information. 

2 1 . The method as recited in claim 16, further comprising the step 
of searching the payment information. 

22. The method as recited in claim 16, further comprising the step 
of exporting the payment information to a software application. 

23. The method as recited in claim 1, wherein the VPL is associated 
with a user, the method further comprising the step of generating an 
expected payment record when the user expects the receipt of an electronic 
payment by the VPL. 
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24. The method as recited in claim 23, further comprising the steps 

of: 

reporting the receipt of electronic payments in the form of a 
payment records; and 

reconciling the payment records with the expected payment records. 

25. The method as recited in claim 1, wherein at least one of the 
received electronic payments originated from a payor, the method further 
comprising the step of receiving a payment confirmation from the payor 
confirming a transmission of the at least one electronic payment. 

26. The method as recited in claim 25, wherein the payment 
confirmation is received through the Internet. 

27. The method as recited in claim 25, wherein the payment 
confirmation is received by E-mail. 

28. The method as recited in claim 25, further comprising the step 
of generating an expected payment record in expectation of the receipt of 
an electronic payment by the VPL. 

29. The method of claim 28, further comprising the step of 
reconciling payment confirmations with expected payment records. 

30. A method for a merchant to receive electronic payments, the 
method comprising the steps of: 

establishing a receive only account denoted as a Virtual Private 
Lockbox (VPL), the VPL having a first address for receiving the electronic 
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payments; 

offering goods or services for sale at an Internet website of the 
merchant; 

transmitting a payment message to a customer who has selected a 
good or service for purchase, the payment message identifying the first 
address and a purchase price; and 

the VPL receiving an electronic payment in the amount of the 
purchase price from the customer. 

31. The method as recited in claim 30, wherein the step of receiving 
the electronic payment further comprises the step of receiving the 
electronic payment through an Electronic Funds Transfer network. 

32. The method as recited in claim 30, further comprising the step 
of generating an account receivable record after the step of transmitting the 
payment message, the account receivable record identifying the customer 
and the purchase price. 

33. The method as recited in claim 32, further comprising the step 
of receiving a payment confirmation from the customer, the payment 
confirmation confirming transmission of the electronic. 

34. The method of claim 33, further comprising the step of 
reconciling payment confirmations with account receivable records. 

35. The method of claim 33, further comprising the step of releasing 
the selected goods to the customer after receipt of the payment 
confirmation. 
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36. The method of claim 35, wherein the selected goods are digital 
in nature, the step of releasing the selected goods further comprises the step 
of transmitting the selected goods to the customer over the Internet. 

37. The method of claim 35, wherein the selected goods are 
physical in nature, the step of releasing the selected goods further 
comprises the steps of: 

notifying a warehouse of the releasing of the goods; and 
contacting a shipper to arrange for shipment of the selected goods. 

38. A Virtual Private Lockbox (VPL) account system comprising: 

a first address into the VPL account, the first address being a receive 
only address for receiving electronic payments into the VPL account; and 
a second address for sweeping funds out of the VPL account, 
5 wherein the second address is only accessible by a supervisor of the VPL 

account. 

39. The system as recited in claim 38, wherein the first address is 
accessible by an Electronic Funds Transfer network, the electronic 
payments being received by the first address as credits over the Electronic 
Funds Transfer network. 

40. The system as recited in claim 39, wherein the electronic 
payments represents unique credits and not reversals of previous debits. 

41. The system as recited in claim 38, wherein the supervisor is a 

bank. 
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42. The system as recited in claim 38, further comprising a third 
address into the VPL account, wherein a user of the VPL account has 
access to the third address for transferring funds out of the VPL account. 

43. The system as recited in claim 42, wherein the first, second and 
third addresses are different. 

44. The system as recited in claim 38, wherein the VPL account is a 
bank account maintained at a bank. 

45. The system as recited in claim 38, wherein the VPL account is 
maintained at an institution. 

46. The system as recited in claim 45, wherein the first address 
includes an address of the institution. 

47. The system as recited in claim 38, further comprising: 
an account reporting module coupled to the VPL account, the 

account reporting module reporting the receipt of the electronic payments 
by the VPL account. 

48. The system as recited in claim 38, further comprising: 
a transaction database; and 

an account reporting module coupled to the VPL account and 
coupled to the transaction database, the account reporting module storing 
5 payment information in the transaction database with respect to each 

electronic payment received by the VPL account. 
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49. The system as recited in claim 48, wherein the account reporter 
enables viewing of the payment information stored in the transaction 
database. 

50. The system as recited in claim 48, wherein the payment 
information includes a source, date and amount of the electronic payment. 

51. The system as recited in claim 48, wherein the account reporter 
enables sorting of the payment information stored in the transaction 
database. 

52. The system as recited in claim 48, wherein the account reporter 
enables editing of the payment information stored in the transaction 
database. 

53. The system as recited in claim 48, wherein the account reporter 
enables searching of the payment information stored in the transaction 
database, 

54. The system as recited in claim 48, wherein the transaction 
database stored an expected payment records when the receipt of an 
electronic payment by the VPL account is expected. 

55. The system as recited in 54, wherein the account reporter 
reconciles the payment records with the expected payment records. 



WO 00/67220 PCT/US00/12059 



1/10 





SUBSTITUTE SHEET (RULE 26) 



WO 00/67220 PCT/US00/12059 



2/10 




o 

CO 



*co 



in 



T 












CO 








O 








CO 







Z 

o 
E 



z 



OS 

O 
co 

CO 

O 
OS 
Cu 

i 

o 

E— 

z 



7 



Z5< 



5= 
o 



e 



o 



O 




coco 



O 

2 
o 

< 



e 



&/1 



CO 



CO 

Z 
O 



00 



~z 
oo 



T 



© 



d 



BNSDOClO <WO 00£7220Al I > 



SUBSTITUTE SHEET (RULE 26) 



WO 00/67220 PCT/US00/12O59 



3/10 



O 
oo 




□MCrwin -iajo nnA70onA 1 



SUBSTITUTE SHEET (RULE 26) 



PCT/US00/12059 



4/10 





O 



o 

■<N 



b 



SUBSTITUTE SHEET (RULE 26) 



WO 00/67220 



PCT/US00/12059 



5/10 





iCC/ — \ — 




to 



fee 

o 

ZD 
< 

2 



O 



c/3 








NSUMR 


BANK 


o 







oo 



r 



o 



in 

b 



SUBSTITUTE SHEET (RULE 26) 



WO 00/67220 PCTYUS00/12059 



6/10 



o 




o 
oo 



ZUJ 




< 

s 



z 

oo^ O 

z<:_<z 

^PQ O 



ZS< 
c£z 

o 



E3 



CO 

O 

DQ 



TATION 
















O 











r 


CATION 


o 

CM 






CERT! 


O 



ACCOUNT 
REPORTER 


§ 


VIRTUAL 
PRIVATE 
LOCKBOX 
(VPL) 


— 



o 

XT 



o 



o 

OO 

oo 

O 
a- 

O 
Z 



7 



cm 



to 

CO 




oooo 



o 
z 



IX] 



&/1 



oo 
Z 
O 



z 

<: 



<u 



r 



o 



a 



SUBSTITUTE SHEET (RULE 26) 



WO 00/67220 



PCT/US00/12059 



7/10 



XQ^O 



o 
oo 




SUBSTITUTE SHEET (RULE 26) 



BNSDOCID <WO 



0067220A1 1 > 



WO 00/67220 



PCT/US00/12059 



8/10 



O 

o 



CO 



8g 



UJ>*CO 
CO 



z 

O 

E-° E— jE— 

^-<: z 



O 

-CO 
CO 



X 



o 
o 

CO 



o 

CO 



to 



-J 



CO 
— 1 

I 



o 

CO 
CO 
U-l 



o 

ex. 




a: 
o 

<: 
z 



o 



7 

CM 



1 



in 



2 



CO 

Zco 
EZ 

o< 
to 



oz 

Is 

coco 

r,CO 



in 
o 

CM 



CO 

O 



O 
o 



&/1 



CO 



co 
Z 
O 

o 



PQ 




r 

o 
m 



oo 

a 

l-H 



SUBSTITUTE SHEET (RULE 26) 



WO 00/67220 PCT/US00/12059 



9/10 




CQ<- 



o 



WSER 


LLET 




o 




cu 




0 





O 




oo 

ON 



b 



SUBSTITUTE SHEET (RULE 26) 



WO 00/67220 



PCT/USOO/12059 



10/10 



<00 



in 




o 

oo 



ZW 




























CQ 





o 
o 




7 



z 
o 

E 



oo^ O 

<qLo£^> 



82 



O 

CO 

O 

OS 
Cu 

I 

O 
cu 

Z 
U-) 



o 
o 



o 



CM 



o 









ON 




AT10N 














TIFI 






W01 




CER 



7 



to 



I 




3=0 

OOOO 



in 
o 

CM 



o 



o 

IS) 

2 
o 

< 



s 



e 



oo 



OO 

Z 
O 



z 

CO 



— z 

OO 



r 



o 
m 



o 



SUBSTITUTE SHEET (RULE 26) 



INTERNATIONAL SEARCH REPORT 



Inte I on at Application No 

PCT/US 00/12059 



A. CLASSIFICATION OF SUBJECT MATTER 

IPC 7 G07F19/00 



According to International Patent Classification (IPC) or to both national classification and IPC 



8. FIELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 

IPC 7 G07F G06F 



Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched 



Electronic data base consulted during the international search (name of data base and. where practical, search terms used) 

EPO-Internal 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category ° 


Citation of document, with indication, where appropriate, of the relevant passages 


Relevant to claim No. 


X 


US 5 677 955 A (ANDERSON MILTON M ET AL) 

14 October 1997 (1997-10-14) 

column 2 -column 6 

column 7, 1 ine 21 - 1 i ne 38 


1-55 


P,X 


US 5 920 847 A (KOLLING RAY ET AL) 

6 July 1999 (1999-07-06) 

the whole document 

column 12, line 24 - line 27 

column 16, line 39 - line 40 

claim 1 

figure 4 

figure 8 


1-55 


X 


US 5 465 206 A (HILT JAMES J ET AL) 
7 November 1995 (1995-11-07) 
figure 4 


1-55 



Further documents are listed in the continuation of box C. 



ID 



Patent family members are listed in annex. 



* Special categories of cited documents : 

"A" document defining the general state of the art which is not 
considered to be of particular relevance 

"E" earlier document but published on or after the international 
filing date 

"L" document which may throw doubts on priority ciaim(s) or 
which is cited to establish the publication date of another 
citation or other special reason (as specified) 

"O" document referring to an oral disclosure, use. exhibition or 
other means 

"P* document published prior to the international filing date but 
later than the priority date claimed 



"T" later document published after the international filing date 
or pnonty date and not in conflict with the application but 
cited to understand the principle or theory underlying the 
invention 

"X" document of particular relevance; the claimed invention 
cannot be considered novel or cannot be considered to 
involve an inventive step when the document is taken alone 

"Y" document of particular relevance; the claimed invention 

cannot be considered to involve an inventive step when the 
document is combined with one or more other such docu- 
ments, such combination being obvious to a person skilled 
in the art. 

"&* document member of the same patent family 



Date of the actual completion of the international search 

28 September 2000 


Date of mailing of the international search report 

06/10/2000 


Name and mailing address of the ISA 

European Patent Office. P.B. 5818 PatentJaan 2 
NL - 2280 HV Rifswi|k 
Tel. (+31-70) 340-2040. Tx. 31 651 epo nl. 
Fax: (+31-70) 340-3016 


Authorized officer 

Wolles, B 



Form PCT/1SA/210 (sooond sheet) (July 1992) 



page 1 of 2 



INTERNATIONAL SEARCH REPORT 



Inter wial Application No 

PCT/US 00/12059 



C.(Contlnuatlon) DOCUMENTS CONSIDERED TO BE RELEVANT 



Category ° I Citation of document, with indie atioawhere appropriate, of the relevant passages 



Relevant to claim No. 



D. REYES (CHASE MANHATTAN BANK): 
"Receivables and Lockbox" 
TREASURY MANAGEMENT INTERNATIONAL, 
July 1998 (1998-07), XP002131754 
the whole document 

WO 99 10823 A (CITIBANK NA) 
4 March 1999 (1999-03-04) 
abstract 

page 22, paragraph 2 
figures 1,2 



Form PCT1SA/210 (cononuaocn of second shaet) (July 1992) 



page 2 of 2 



BNSDOCID <WO 006 7 220 A 1 I > 



INTERNATIONAL SEARCH REPORT 

..iformation on patent family members 



Inter >nal Application No 

PCT/US 00/12059 



Patent document 
cited in search report 


Publication 
date 


Patent family 
member(s) 


Publication 
date 


Uo OD / /i?OD M 


1 d-1 0—1 QQ7 

14 XU 17 7/ 


BR 


9608448 


A 


07—1 9— 1 QQQ 

U / Ic. 1777 






CA 


2217593 


A 


1 0-1 0—1 QQfi 

1U XU 177U 






EP 


0819345 


A 


91 — HI —1 QQQ 

Ll Ul 177U 






JP 


11503541 


T 


9f\— O^ — 1 QQQ 

to uj iyyy 






UO 


9631965 


A 


1 O—l O—l QQA 

i u l u iyyo 


HQ CQ9nftd7 A 


Ofi— 07— 1 QQQ 
UO U / X 


US 


6032133 


A 


^y— U^— £\j y g 






US 


5465206 


A 


fl7 — 1 1—1 QQC 

u / — i i— iyyb 






AU 


686270 


B 


ub— U2— iyyo 






AU 


8098494 


A 


9*5-_nC — 1 QQC 






BR 


9407964 


A 


00-12— iyyo 






CA 


2175473 


A 


i i-ob— iyyb 






CA 


2175476 


A 


i i _nc_i QQC 

l i-ob— iyyb 






EP 


0727072 


A 


21— uo— iyyo 






HU 


74351 


A 


ju- 12— iyyo 






ID 

or 




D 
D 


nc_n7 1 QQO 

ud— u/— iyyy 






JP 


9504634 


T 


uo— ud— iyy / 






LT 


96060 


A, B 


27-01-1997 






LV 


11648 


A 


20-12-1996 






LV 


11648 


B 


on no i c\c\~t 

20-00-1997 






NO 


961707 


A 


oc nc i nn£ 

^b— uo-iyyo 






NZ 


275027 


A 


oa f\A i 007 
£Q— 04— 1997 






PL 


314309 


A 


no no i c\nc 
U2— 09— 1996 






WO 


9512859 


A 


1 1 AC 1 QQC 

1 l-0b-199b 


U5 54ob20o A 


Q7 11 1 QQC 

u/— l I— lyyb 


AU 


686270 


B 


nr i%o 1 oo o 

Ub-02-199o 






AU 


8098494 


A 


o o nc i one 
23-Qb— 1995 






BR 


9407964 


A 


no i o i nnc 
Ui-12-199o 






CA 


2175473 


A 


i i nc 1 QQC 
1 l-0b-199b 






CA 


2175476 


A 


ii nc 1 QQC 

1 1— 0b— iy9b 






EP 


0727072 


A 


o 1 no i fine 
2 1— 0o— 199o 






HU 


74351 


A 


on to 1 fiOC 

ou— 12— iyyo 






JP 


2916543 


B 


nc_n7 i qqo 

ub— u /— iyyy 






JP 


9504634 


T 


n/i nc i oo*7 

uo— ob— iyy / 






L 1 


youou 


A R 
A , D 


07_rt n i QQ7 

2/— u i-iyy / 






LV 


11648 


A 


on 1 O 1 QQC 

2u— 12 iyyo 






LV 


11648 


B 


20-08-1997 






Kin 


Q£ 1 7H7 

yo i / u / 


A 

A 


25-06-1996 






NZ 


275027 


A 


OA f\A 1 OO 7 

«£»*— u*t— iyy/ 






PL 


314309 


A 


02-09-1996 






WO 


9512859 


A 


11-05-1995 






US 


6032133 


A 


29-02-2000 






US 


5920847 


A 


06-07-1999 


WO 9910823 A 


04-03-1999 


AU 


9111798 


A 


16-03-1999 






EP 


1010118 


A 


21-06-2000 





Form PCT.1SA/210 (paieni family annex) (July 19921 



<WO 0067220A1 



